CHAPTER 4
Everything in Visual Basic (VB) is an object. As VB is an object-oriented language, the objects that you create through class definitions have all the same capabilities of the other predefined objects in the system. In fact, keywords such as Integerand Boolean are merely aliases to pre-defined value types within the System namespace, System.Int32, and System.Boolean, respectively.
The ability to invent your own types is an integral part of object-oriented systems. The cool thing is that, since even the built-in types of the language are plain-old common lan-guage runtime (CLR) objects, the objects you create are on a level playing field with the built-in types. In other words, the built-in types don’t have special powers that you cannot muster. The cornerstone for creating these types is the class definition. Class definitions, using the Classkeyword, define the internal state and the behaviors associated with the objects of that class’s type.
The internal state of an object is represented by the fields that you declare within the class, which can consist of references to other objects or values. The objects created from a class encapsulate the data fields that represent the internal state of the objects, and the objects can tightly control access to those fields.
The behavior of the objects is defined by implementing methods, which you declare and define within the class definition. By calling one of the methods on an object instance, you initiate a unit of work on the object. That work can possibly modify the internal state of the object; inspect the state of the object, or anything else for that matter.
You can define constructors, which the system executes whenever you create a new object. You can also define a method called a finalizer, which is called when the object is garbage-collected. As you’ll see later, you should avoid writing your own finalizer if at all pos-sible. This chapter covers construction and destruction in detail, including the detailed sequence of events that occur during the creation of an object.
The CLR tracks object references. This means each variable of reference type actually con-tains a reference to storage on the heap (or is null, if it doesn’t currently refer to an object). When you copy the value of a reference type variable into another reference type variable, you create another reference to the same object—in other words, the reference is copied. Thus, you end up with two variables that reference the same object. In the CLR, you have to do extra work to create copies of objects—e.g., you must implement the ICloneable interface or a simi-lar pattern.
All objects created from class definitions reside on the system heap, which the CLR garbage collector (GC) manages. The GC relieves you from the task of cleaning up your objects’ memory. You can allocate them all day long without worrying about who will free the memory associated with them. The GC is smart enough to track all of an object’s references, and when it notices that an object is no longer referenced, it marks the object for deletion. Then, the next time the GC compacts the heap, it destroys the object and reclaims the memory.
Along with classes, the VB language supports the definition of new value types through the Structurekeyword. Structures are sort of lightweight objects that typically don’t live on the heap, but instead live on the stack. Structures cannot be defined to inherit from another class or structure, nor can another structure or class inherit from them.
Structures can have constructors, but they cannot have a finalizer. Structures can have events, but you must fire them manually, using RaiseEvent. By default, when you pass value types into methods as parameters, the method receives a copy of the value.
That said, let’s dive in and get to the details. Don’t be afraid if the details seem a little over-whelming at first. The fact is, you can start to put together reasonable applications without knowing every single detailed behavior of the language. That’s a good thing, because VB, along with the Visual Studio Integrated Development Environment (IDE), is meant to facilitate rapid application development. It goes without saying, however, that the more details you know about the language and the CLR, the more effective you’ll be at developing and designing robust applications.
Let’s go ahead and have a look at a simple class now, so you can get a feel for things:
Public Class Customer
'Fields/Members
Private mName As String
Private mCustomerID As Integer
'Constructor
Public Sub New()
MyBase.New()
End Sub
'Properties
Public Property Name() As String
Get
Return mName
End Get
Set(ByVal value As String)
mName = value
End Set
End Property
Public Property CustomerID() As Integer
Get
Return mCustomerID
End Get
Set(ByVal value As Integer)
mCustomerID = value
End Set
End Property
'Methods
Public Function SaveCustomerToDB() As Boolean
'Put code for this function here.
'For now, return success
Return True
End Function
End Class
This class declaration defines a Customerclass. The access modifier in front of the Class keyword, in this case Public, controls the visibility of the type from outside the assembly. The class Customer is publicly accessible, which means that consumers of the assembly that con-tains this class can create instances of this class. The Customer class contains two fields, a constructor, two property setters/getters, and one function. The property methods allow read/write access to the fields, and the function is used to save the customer to a database.